home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9651 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: news.luc.edu!user
  2. From: VArase@varase.it.luc.edu (Verne Arase)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: malloc question
  5. Date: Tue, 12 Mar 1996 10:16:13 -0600
  6. Organization: LUMC
  7. Message-ID: <AD6AFF6D9668E8DB7@mcdiala09.it.luc.edu>
  8. References: <4htonk$350@news.hklink.net> <314318AF.30F@iperbole.bologna.it> <4hvaj4$laj@solutions.solon.com> <AD69AACE9668D78B0@mcdiala09.it.luc.edu> <4i1kq3$2m0@solutions.solon.com>
  9. NNTP-Posting-Host: 147.126.240.109
  10.  
  11. In article <4i1kq3$2m0@solutions.solon.com>,
  12. seebs@solutions.solon.com (Peter Seebach) wrote:
  13.  
  14.  >>In this specific case, however, it _never_ hides an error. If malloc is
  15.  >>used in its standard context, we are simply coercing a slab of memory
  16.  >>aligned to the most stringent boundaries into a pointer of the desired
  17.  >>type.
  18.  >
  19.  >Which does *nothing*, because void pointers always convert to the desired
  20.  >type silently and automatically.
  21.  
  22. Provided you're not dealing with a pre-ANSI compiler.
  23.  
  24.  >Further, it *did* hide an error in the specific case; <stdlib.h> was not
  25.  >included, and there was no prototype in scope.
  26.  >
  27.  >>Provided the associated header is included (and the memory model doesn't
  28.  >>change through some devious, manual manipulation), you are _always_ safe
  29. in
  30.  >>coercing a malloc allocated block of memory into the desired pointer
  31. type.
  32.  
  33. Then that was what should have been said.
  34.  
  35.  >And you are _always_ redundant doing so, unless you're passing to a
  36.  >varaidic function or one with no prototype in scope.
  37.  
  38. I had a pre-ANSI compiler which defined malloc as returning char *.
  39.  
  40.  >char is not a signed quantity.  char is a quantity which may be signed or
  41.  >unsigned.
  42.  
  43. Every implementation I've seen makes char signed.
  44.  
  45.  >It's a question of usage.  An unspecified short, int, or long is *always*
  46.  >signed, so it is clearly desireable for char to be signed.  EOF is
  47.  >negative, and the getc family all return unsigned char or EOF, so it is
  48.  >clearly desireable for char to be unsigned.
  49.  
  50. While you'd probably want a short, int, or long to be signed, what's the
  51. percentage of time you actually _want_ char to be signed? And what's the
  52. percentage of time you gave a hoot whether you had a char * or an unsigned
  53. char *?
  54.  
  55. As for the getc routines: don't have any C references here, but don't they
  56. return an int?
  57.  
  58.  >If you don't put in casts, you will get warnings for any conversion not
  59.  >normally correct.  This is helpful.
  60.  
  61. Depends on the compiler.
  62.  
  63. I've had IDEs where an uncasted pointer conversion just produced an error
  64. and stopped the compile.
  65.  
  66. Anyhow, I accidently let that last post out; I'd been intending to nuke it,
  67. but forgot and it was transmitted with my last news poll. Sorry for the
  68. extra traffic in the newsgroup.
  69.  
  70. ---
  71. The above are my own opinions, and not those of my employer.
  72.